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Abstract 

Tactical  networking  environments  present  sig¬ 
nificant  challenges  that  must  be  overcome  in 
order  to  effectively  support  net-centric  warfare. 
The  wireless  and  ad  hoc  nature  of  these  net¬ 
works  implies  unreliable  connectivity,  limited 
bandwidth,  and  variable  latency.  Past  and  cur¬ 
rent  research  has  focused  on  physical  and  data 
link  layers,  routing  protocols,  transport  proto¬ 
cols,  and  cross-layer  aspects.  However,  signifi¬ 
cant  work  is  needed  at  the  upper  layers  to  better 
support  application  requirements.  In  our  experi¬ 
ence,  achieving  effective  communications  in  tac¬ 
tical  environments  requires  taking  into  account 
application  requirements  and  communication 
patterns,  designing  a  rich  interface  between  the 
application  and  communication  layers,  and  real¬ 
izing  a  communications  middleware  specifically 
adapted  to  tactical  networks.  In  this  article,  we 
report  on  our  observations  from  several  tactical 
networking  experiments  and  demonstrations  and 
the  lessons  learned  from  deployment  of  the 
Mockets  middleware  to  support  tactical  commu¬ 
nications.  We  hope  these  experiences  are  useful 
to  others  designing  and  implementing  applica¬ 
tions  and  systems  for  tactical  environments. 

Introduction 

Network-centric  operations  [1],  also  referred  to 
as  network-enabled  capability  and  network- 
based  defense,  is  the  cornerstone  of  modern 
warfighting.  These  approaches  rely  on  robust 
network  communications  to  support  timely 
exchange  of  information  between  geographically 
dispersed  entities.  However,  tactical  networks, 
the  basis  for  network-centric  operations,  provide 
one  of  the  most  challenging  environments  for 
communications  (Fig.  1).  The  inherently  mobile 
nodes  must  communicate  by  using  wireless  ad 
hoc  links  in  hostile  radio  frequency  (RF)  envi¬ 
ronments,  creating  unreliable  networks  that  have 
limited  bandwidth  and  variable  latency.  More¬ 


over,  the  dynamic  nature  of  military  operations 
results  in  widely  varying  loads  being  placed  on 
the  network  by  users  and  applications.  Develop¬ 
ing  effective  communication  and  networking 
technologies  for  tactical  environments  is  essen¬ 
tial  for  Network  Centric  Operations. 

Research  to  date  on  tactical  wireless  commu¬ 
nications  has  focused  on  increasing  bandwidth, 
improving  reliability,  and  enabling  adaptation  by 
focusing  on  areas  such  as  network  coding, 
dynamic  spectrum  exploitation,  robust  routing 
protocols,  and  cross-layer  design.  Researchers 
have  also  proposed  new  transport  protocols  such 
as  the  Stream  Control  Transport  Protocol 
(SCTP)  [2],  the  Transport  Protocol  of  the  Space 
Communications  Protocol  Standards  (SCPS-TP) 
[3],  and  TCP  enhancements  [4].  However,  our 
experience  shows  that  there  is  much  potential 
for  improvement  in  the  realization  of  communi¬ 
cations  middleware  and  application  interfaces. 
Understanding  application  requirements  and 
communication  patterns,  and  designing  protocols 
to  better  support  them  is  essential  for  providing 
good  performance.  For  example,  transport  pro¬ 
tocols  must  provide  a  rich  interface  to  better 
understand  application  intent  and  provide  feed¬ 
back  so  that  applications  may  adapt  to  underly¬ 
ing  network  conditions.  Applications  in  tactical 
networks  have  different,  sometimes  peculiar, 
requirements;  therefore,  a  one  size  fits  all 
approach  to  transport  protocols  leads  to  ineffi¬ 
ciencies. 

This  article  describes  observations  and  expe¬ 
riences  gathered  from  participating  in  multiple 
real-world  experiments  and  demonstrations  of 
net-centric  operations  in  tactical  environments  in 
partnership  with  the  U.S.  Army  Research  Labo¬ 
ratory  (ART)  and  the  U.S.  Air  Force  Research 
Laboratory  (AFRL).  These  include  the  Horizon¬ 
tal  Fusion  Quantum  Leap  experiments  in  2003 
and  2004  (QL-1  and  QL-2),  the  Communica- 
tions-Electronics  Research,  Development,  and 
Engineering  Center  (CERDEC)  C4ISR  On  the 
Move  (C4ISR  OTM)  experiments  in  2006,  2007, 
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and  2008,  and  an  airborne  networking  experi¬ 
ment  involving  a  J-STARS  platform  (ANE). 
These  experiences  have  driven  the  design  and 
implementation  of  Mockets,  a  communications 
middleware  that  supports  applications  in  tactical 
environments  through  a  rich  programming 
model.  Two  experiments  with  Mockets  provide  a 
glimpse  of  the  significant  performance  improve¬ 
ments  made  possible  by  the  use  of  a  communica¬ 
tion  framework  developed  specifically  for  tactical 
networks.  Mockets  demonstrates  the  importance 
of  tailoring  the  design  and  implementation  of 
communications  middleware  to  both  the  applica¬ 
tions  and  the  target  environments. 


The  Tactical  Networking 
Environment:  Observations  and 
Lessons  Learned 

In  partnership  with  ART  and  AFRL,  we  have 
conducted  many  experiments  in  tactical  environ¬ 
ments,  which  have  resulted  in  valuable  lessons 
learned.  This  section  summarizes  our  practical 
experience,  the  actual  problems  encountered 
with  application  and  radio  behavior  in  tactical 
network  environments,  and  the  associated  impli¬ 
cations  for  communications  middleware.  Note 
that  in  this  article  we  do  not  consider  satellite 
communications. 

To  better  present  our  observations,  we  use 
Blue  Force  Tracking^  (BFT)  as  an  example 
application  throughout  this  article.  BFT  provides 
warfighters  with  location  information  about 
friendly  military  forces.  Force  XXf  Battlefield 
Command  Brigade  and  Below  (FBCB2)  is  a  cur¬ 
rently  fielded  BFT  system.  A  number  of  other 
BFT  systems  are  in  development. 

BFT  systems  use  terrestrial  and  satellite 
communication  links  to  exchange  GPS  position 
and  related  situational  awareness  information. 
Receiving  nodes  display  the  location  of  friendly 
forces  by  using  a  mapping  system.  BFT  systems 
can  also  support  other  communications,  such  as 
text  messages  and  images,  as  well  as  informa¬ 
tion  on  hostile  forces  and  battlefield  obstacles. 
BFT  systems  may  also  be  integrated  with  other 
battlefield  systems  such  as  robotic  operator 
control  units  (OCUs)  and  sensor  management 
software.  BFT  systems  operate  on  real-time 
information  and  must  satisfy  strict  latency  con¬ 
straints,  as  outdated  position  information  can 
be  misleading. 

Limited  Bandwidth  and 
Intermittent  Connectivity 

Bandwidth  in  tactical  networks  is  severely  limit¬ 
ed,  and  the  throughput  achieved  in  real-world 
scenarios  is  often  far  less  than  the  system  specifi¬ 
cations  would  suggest.  For  example,  during  the 
QL-2  experiment,  we  used  a  custom  802. llg- 
based  wireless  ad  hoc  IP  radio  node.  802. Ifg- 
based  radios  provide  a  theoretical  data  rate  of 
54  Mb/s,  which  decreases  to  15-30  Mb/s  in  a  typ¬ 
ical  office  environment.  During  the  experiment 
we  observed  an  average  usable  throughput  of 
1-1.5  Mb/s,  which  is  an  order  of  magnitude 
lower  than  expected.  The  poor  performance  can 


Figure  1 .  Conceptual  view  of  a  tactical  networking  environment. 


be  attributed  to  the  high  churn  rate,  RF  interfer¬ 
ence,  and  zones  with  poor  connectivity. 

Most  current  and  planned  military  radio  sys¬ 
tems  have  even  lower  bandwidth  than  802. llg 
radio  platforms  due  to  additional  range,  inter¬ 
ference,  mobility,  and  security  requirements. 
Experimentation  with  a  prototype  of  the  SLICE 
radio,  an  IP  radio  that  implements  Joint  Tacti¬ 
cal  Radio  Standards  (JTRS)  Soldier  Radio 
Waveform  (SRW),  showed  a  maximum 
throughput  of  well  under  1  Mb/s  shared  across 
all  nodes.  This  radio  also  has  a  very  high  per- 
packet  overhead  that  significantly  reduces  the 
effective  bandwidth  when  an  application  trans¬ 
mits  small  packets. 

Moreover,  application  bandwidth  require¬ 
ments  are  often  underestimated.  Due  in  part  to 
poor  architectural  decisions,  the  BFT  application 
used  for  QL-2  consumed  approximately  0.5 
Mb/s.  Therefore,  very  little  bandwidth  was  avail¬ 
able  for  other  tasks  such  as  obtaining  sensor 
data  (including  video  feeds),  interpersonal  com¬ 
munication,  and  robot  tele-operation  (requiring 
video  feeds). 

Our  experience  has  also  shown  that  tactical 
networks  are  subject  to  intermittent  connectivity 
problems.  In  particular,  urban  environments 
have  many  dead  spots,  which  cause  nodes  to  lose 
connectivity.  In  a  tactical  network,  where  traffic 
is  relayed  through  multiple  hops,  the  loss  of  con¬ 
nectivity  to  one  node  may  affect  connectivity  to 
other  nodes.  Tele-operated  robots,  increasingly 
common  on  the  battlefield,  present  additional 
complications.  A  robot  that  is  driven  into  a  dead 
spot  can  become  stuck  due  to  its  inability  to 
receive  commands  and  require  manual  retrieval, 
which  is  not  always  possible  or  practical. 


Frequent  and  Abrupt  Variations  in 
Channel  Conditions  and 
Network  Topology 

Tactical  network  environments  present  turbu¬ 
lent  and  chaotic  network  conditions.  This  stems 
from  the  inherent  characteristics  of  radio  com¬ 
munication  systems  including  fading,  interfer- 


1  In  the  MIL-STD-2525 
symbology  standard, 
friendly  forces  are  desig¬ 
nated  with  blue  symbols, 
enemy  forces  are  designat¬ 
ed  with  red,  and  unknown 
forces  with  yellow. 
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ence,  and  channel  contention,  resulting  in  highly 
variable  bandwidth  with  time  and  spatial  depen¬ 
dencies  [5]. 

Mission  execution,  responses  to  enemy  activi¬ 
ty,  and  changing  tactical  objectives  cause  massive 
unit  movements  that  are  difficult  for  the  network 
to  predict  in  advance.  Network  disruption  and 
reconfiguration  resulting  from  this  node  mobility 
and  churn  cause  major  fluctuations  in  end-to- 
end  channel  conditions.  Additional  complica¬ 
tions  arise  from  velocity  differences  between  air 
and  ground  units  [6].  As  a  result,  applications 
that  assume  continuous  connectivity  in  a  steady 
state  mode  suffer  from  performance  problems 
and  fail  in  these  conditions. 

Varied  Types  of  Data 

Applications  in  tactical  networks  are  extremely 
heterogeneous,  ranging  from  sensor  data  dissem¬ 
ination  and  BFT  to  robotic  tele-operation  and 
voice  over  IP  (VoIP).  Furthermore,  data  types 
vary  from  continuous  streams  (e.g.,  video)  to  dis¬ 
crete  messages  (e.g.,  individual  sensor  reports). 
Each  of  these  activities  potentially  demands  dif¬ 
ferent  types  of  service  from  the  communications 
network.  We  refer  to  a  set  of  related  messages 
with  homogeneous  service  and  message  delivery 
semantics  as  a  data  flow.  Data  flows  may  require 
sequential  message  delivery  and/or  different  reli¬ 
ability  levels. 

Some  data  flows  contain  independent  mes¬ 
sages  and  do  not  have  sequencing  constraints, 
while  others  require  message  sequencing,  typi¬ 
cally  on  a  per  flow  basis.  In  our  experience  only 
a  very  small  number  of  applications  require 
sequential  delivery  across  all  data  flows.  In  addi¬ 
tion,  some  data  flows  carry  critical  information 
that  require  reliable  message  delivery,  while  oth¬ 
ers  carry  non-time-sensitive  or  disposable  infor¬ 
mation  that  can  be  sent  in  a  best  effort  or 
partially  reliable  manner.  Reliability  and 
sequencing  are  orthogonal  characteristics. 

For  example,  BFT  systems  deal  with  separate 
data  flows.  Information  about  units  does  not 
have  sequencing  delivery  constraints,  but  needs 
partial  reliability.  Position  updates  do  not  have 
reliability  constraints,  but  require  intraflow 
sequencing  as  well  as  sequencing  with  the  last 
full  unit  information  message.  Other  examples 
include  sensor  reports,  which  require  reliability, 
and  tele-operation  and  VoIP,  which  require  low 
latency. 


Resource  Prioritization 

As  a  result  of  reliability,  sequencing,  and  latency 
requirements,  different  data  flows  in  a  tactical 
network  have  different  priorities.  For  example, 
low-latency  flows  such  as  a  video  feed  from  a 
robot  have  higher  priority  than  sensor  reports 
that  will  not  be  viewed  in  real  time.  In  addition, 
not  all  video  streams  from  the  robot  have  equal 
priority.  The  video  stream  for  the  driver  has 
higher  priority  than  a  video  stream  for  an  observ¬ 
er,  as  the  driver  is  vastly  more  sensitive  to  laten¬ 
cy  than  the  observer.  As  tactical  objectives  and 
environmental  conditions  change  over  time,  the 
priority  of  different  data  flows  will  change  as 
well.  This  was  particularly  important  when  we 
tele-operated  a  robot  using  a  SLICE  radio  at  the 
2007  C4ISR  OTM  experiment.  The  radio’s  con¬ 


strained  bandwidth  required  us  to  exploit  a  fea¬ 
ture  of  the  radio  where  a  single  high-priority 
data  flow,  in  this  case  the  driver’s  video,  is  sent 
using  a  special  high-bandwidth  mode  at  the 
physical  layer  and  takes  priority  over  all  other 
traffic  on  the  network. 

Data  Queuing 

When  an  application  exceeds  the  available  net¬ 
work  bandwidth,  data  may  accumulate  in  a  trans¬ 
mission  queue  in  the  application,  operating 
system,  or  radio.  When  these  queues  become 
full,  new  data  will  be  dropped  or  the  application 
will  block  until  the  queue  starts  to  empty. 

Data  queuing  causes  temporary  spikes  and 
long-term  drifts  in  end-to-end  latency  along  with 
transmission  of  unnecessary  data.  For  example, 
if  a  node  generating  BFT  information  at  a  rate 
of  1  FIz  loses  network  connectivity  for  30  s,  the 
transmission  queue  will  accumulate  30  messages. 
When  connectivity  is  restored,  all  30  messages 
will  be  transmitted  in  the  order  they  were  origi¬ 
nally  generated.  Since  the  only  message  of  inter¬ 
est  is  the  most  recent  position  update,  the 
preceding  29  messages  waste  bandwidth  and 
increase  latency. 

It  is  extremely  difficult  for  applications  to 
mitigate  the  impact  of  data  queuing  on  their 
overall  performance  as  they  have  no  control  over 
data  already  in  the  transmission  queue.  While 
careful  application  design  and  protocol  selection 
can  minimize  or  eliminate  the  impact  of  queuing 
at  the  application  and  operating  system  levels, 
this  does  not  eliminate  the  potential  for  queuing 
at  the  network  level. 

During  the  QL-1  experiment,  our  first 
attempt  used  TCP  to  send  all  data,  including 
video  streams.  When  the  network  deteriorated, 
video  latency  increased  without  bound  due  to 
the  blocking  behavior  of  TCP.  The  latency  of  the 
resulting  video  stream  rendered  it  useless.  Dur¬ 
ing  2007  C4ISR  OTM,  we  encountered  a  similar 
problem  with  the  SLICE  radio,  which  contains  a 
very  large  internal  transmit  buffer  on  the  order 
of  1000  packets.  Although  we  had  redesigned 
our  applications  to  minimize  buffering  and  elim¬ 
inate  the  use  of  TCP,  the  message  queuing  at 
the  SLICE  radio  caused  problems.  The  amount 
of  data  being  transmitted  had  to  be  carefully 
controlled  to  avoid  intolerable  latencies. 

Legacy  Applications  and  Systems 

Many  legacy  applications,  protocols,  and  systems 
are  currently  used  in  tactical  environments. 
These  are  usually  derived  from  commercial  off- 
the-shelf  (COTS)  applications  developed  for  the 
Internet.  They  use  existing  protocols  such  as 
TCP  and  UDP,  and  make  assumptions  about 
network  services,  bandwidth,  and  availability 
based  on  characteristics  of  the  public  Internet. 
These  assumptions  do  not  hold  for  tactical  wire¬ 
less  networks,  and  lead  to  performance  and  reli¬ 
ability  problems. 

The  use  of  TCP  is  a  particularly  important 
problem.  TCP  was  designed  for  fully-connected 
wired  and  wireless  infrastructure  networks  and, 
as  evidenced  by  its  worldwide  adoption  and  suc¬ 
cess,  functions  extremely  well  on  these  types  of 
networks.  However,  TCP’s  congestion  control 
and  retransmission  behavior  was  not  designed 
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for  intermittently  connected  networks  and  is 
often  inefficient  or  too  aggressive  in  these  envi¬ 
ronments  [7].  Finally,  TCP’s  (intentionally)  sim¬ 
plistic  interface  does  not  allow  an  application  to 
distinguish  between  different  messages  and  pro¬ 
vide  additional  contextual  information  (e.g.,  pri¬ 
ority)  regarding  the  messages  being  sent  by  the 
application.  While  TCP  permits  transmission  of 
out-of-band  high-priority  data,  this  feature  pro¬ 
vides  only  two  priority  levels  (normal  and  high), 
presents  an  interface  that  is  not  consistent  or 
compatible  across  platforms,  and  does  not  fit  in 
the  stream-oriented  communication  channel 
abstraction.  As  a  result,  this  feature  of  TCP  is 
rarely,  if  ever,  utilized. 

Common  industry  standards  such  as  Web  ser¬ 
vices,  HTTP,  and  some  peer-to-peer  protocols 
such  as  Sun’s  JXTA  make  use  of  TCP.  These 
standards  have  been  adopted  by  military  systems 
running  on  higher-echelon  (organizations  at  the 
level  of  a  brigade  and  above)  command  and  con¬ 
trol  networks  [8].  TCP  functions  adequately  in 
such  environments,  as  they  are  essentially  infra¬ 
structure  networks.  However,  when  these  appli¬ 
cations  are  pushed  down  to  the  tactical  level,  the 
limitations  of  TCP-based  COTS  systems  become 
apparent. 

Requirements  for 
Communications  Middleware  in 
Tactical  Networks 

Earlier  we  discussed  the  challenges  posed  by  tac¬ 
tical  wireless  environments,  which  need  to  be 
mitigated  through  explicit  support  at  the  middle¬ 
ware  level.  This  section  presents  a  set  of  require¬ 
ments  for  communications  middleware  to 
address  these  challenges.  As  the  resources  avail¬ 
able  are  limited,  the  primary  requirement  is  to 
enable  the  application  and  communications  mid¬ 
dleware  to  jointly  perform  trade-offs  between 
competing  demands  to  improve  overall  perfor¬ 
mance. 

Application  Awareness  of 
Communication  State 

Tactical  networks  are  characterized  by  limited 
bandwidth  and  intermittent  connectivity.  This 
suggests  a  fundamental  requirement  for  applica¬ 
tion  design:  a  continuous  adaptation  process  to 
match  both  changing  tactical  objectives  and  net¬ 
work  conditions,  instead  of  assuming  steady- 
state  operations.  Adaptive  application  design 
involves  an  in-depth  reconsideration  of  the  com¬ 
munication  stack  in  order  to  support  preemp¬ 
tion,  dynamic  reallocation,  efficient  use,  and 
status  monitoring  of  network  resources. 

Continuous  adaptation  requires  the  middle¬ 
ware  to  support  a  rich  programming  model  that 
provides  accurate  and  timely  feedback  on  net¬ 
work  status  and  changes  in  resource  availability 
to  enable  application  adaptation  to  highly  vary¬ 
ing  conditions.  To  guide  resource  utilization 
decisions,  applications  should  leverage  network 
performance  measurements  including  detailed 
statistics  regarding  connection  status  and  data 
transfers. 


In  the  BFT  example,  reducing  the  transmis¬ 
sion  rate  and  prioritizing  the  position  informa¬ 
tion  data  flow  would  preserve  system 
functionality  and  low  latency  despite  a  significant 
drop  in  available  network  resources. 

Applications  also  benefit  from  notifications 
regarding  disconnections  so  that  they  can  adapt 
their  behavior.  With  temporary  disruptions,  con¬ 
nections  should  enter  a  snooze  state  in  which 
data  transmission  is  suspended.  Upon  reestab¬ 
lishing  connectivity,  the  reconnection  procedure 
would  be  triggered.  Applications  could  also  take 
advantage  of  predictions  on  likely  future  channel 
conditions  derived  from  trends  in  signal  strength 
and  signal  to  noise  ratio. 

Multimode  Communications  Support 

Applications  in  tactical  networks  have  multiple 
separate  data  flows  with  differing  requirements. 
However,  commonly  used  transport  protocols 
such  as  TCP  provide  reliable  and  sequenced 
delivery  of  a  single  stream  of  data,  which  is  inef¬ 
ficient  over  unreliable  networks  for  three  rea¬ 
sons.  First,  reliable  delivery  requires 
retransmission  of  lost  or  unacknowledged  pack¬ 
ets.  Second,  the  stream-oriented  abstraction  pre¬ 
vents  the  transport  protocol  from  being  aware  of 
independent  application  messages.  Finally, 
sequenced  delivery  requires  that  data  received 
out  of  order  must  be  retained  at  the  transport 
protocol  level  until  ordering  constraints  have 
been  satisfied.  While  these  are  useful  abstrac¬ 
tions,  they  are  expensive  to  provide  and,  most 
important,  are  not  needed  by  all  applications  at 
all  times. 

Therefore,  the  middleware  should  allow 
applications  to  exploit  different  message  delivery 
semantics  for  each  data  flow,  based  on  their 
needs.  The  communications  middleware  should 
provide  flexible  combinations  of  reliability, 
sequencing,  and  prioritization,  and  allow  appli¬ 
cations  to  specify  their  desired  requirements. 
Providing  this  information  to  the  transport  pro¬ 
tocol  allows  the  middleware  to  better  allocate 
scarce  resources. 

For  instance,  a  BFT  application  might  react 
to  channel  degradation  by  giving  up  reliability 
and/or  sequencing,  or  imposing  a  constraint  on 
the  number  of  packet  retransmissions,  in  order 
to  obtain  lower  end-to-end  latency. 

Advanced  Control  of 
Transmission  Queues 

Data  queuing  deteriorates  performance  and 
increases  latency.  The  middleware  should  pro¬ 
vide  applications  with  explicit  functions  to  deal 
with  time-sensitive  information.  An  important 
approach  to  efficiency  is  to  provide  advanced 
control  of  transmission  queues  to  reduce  latency 
by  minimizing  unneeded  message  transmissions. 

Data  transmitted  in  tactical  networks  is  often 
time  sensitive  (e.g.,  multimedia  and  control 
applications),  which  implies  the  data  has  a  finite 
lifetime.  The  communications  middleware  should 
support  specifying  maximum  lifetimes  for  outgo¬ 
ing  messages  so  that  outdated  messages  may  be 
automatically  discarded.  Additionally,  applica¬ 
tions  should  be  able  to  identify  and  discard  spe¬ 
cific  messages  from  the  transmission  queue, 
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minimizing  transmission  of  unnecessary  data  and 
significantly  improving  latency  for  delivery  of 
necessary  data. 

For  example,  a  BFT  application  might  dis¬ 
card  old  position  updates  for  an  entity  when  a 
new  one  becomes  available. 

Runtime  Control  of  Resource  Allocation 

Bandwidth  scarcity  in  tactical  network  environ¬ 
ments  requires  prioritization  of  channel  access 
between  competing  applications  in  accordance 
with  current  tactical  objectives.  Access  to  net¬ 
work  resources  from  low-priority  or  non-critical 
applications  should  be  preempted  in  favor  of 
critical  applications.  Therefore,  the  middleware 
must  allocate  network  resources  to  competing 
demands  to  improve  overall  effective  perfor¬ 
mance. 

Tactical  objectives  and  environmental  condi¬ 
tions  change  continuously,  causing  frequent  vari¬ 
ations  in  application  priorities  for  channel  access. 
Tools  and  mechanisms  to  dynamically  change 
resource  allocations  to  applications  at  runtime 
are  needed.  A  network  administrator  should  be 
able  to  change  the  runtime  behavior  of  distribut¬ 
ed  applications  with  an  external  policy-based 
control  mechanism  of  runtime  properties.  This 
feature  should  enable  the  dynamic  definition  of 
policies  to  prioritize  channel  access  for  critical 
applications  to  provide  mission  performance  that 
meets  the  commander’s  requirements.  To  sup¬ 
port  administrators  with  this  task,  the  middle¬ 
ware  should  enable  visualization  of  critical 
information  about  network  and  application  per¬ 
formance  over  time. 

In  the  BFT  application,  transmission  of  force 
positions  from  engagement  zones  and  civilian 
zones  are  more  important  than  force  positions  in 
quiescent  zones. 

Integration  Support 

The  heterogeneity  of  applications  and  systems 
adopted  in  tactical  networks  requires  portability 
to  a  wide  range  of  hardware/operating  system 
(OS)  platforms,  ease  of  integration,  and  back¬ 
wards  compatibility  with  legacy  applications. 

The  middleware  should  provide  applications 
with  a  platform-independent  application  pro¬ 
gramming  interface  (API).  In  addition,  tactical 
networking  middleware  should  be  designed  for 
easy  deployment  and  tuning  on  legacy  equip¬ 
ment  and  protocols  commonly  found  in  real-life 
tactical  networks.  Finally,  the  middleware  should 
provide  mechanisms  that  ease  the  migration  of 
legacy  and  COTS  applications  to  tactical  net¬ 
works,  allowing  their  gradual  porting  on  an  as 
needed  basis. 


Related  Work 

Many  research  efforts  have  addressed  the  prob¬ 
lem  of  realizing  efficient  and  robust  communica¬ 
tions  in  tactical  networks  and  other  highly 
dynamic  wireless  networking  environments  [9]. 
Several  studies  focus  on  improving  TCP’s  robust¬ 
ness  and  performance,  with  the  goal  of  preserv¬ 
ing  interoperability  with  the  large  base  of  existing 
TCP-based  applications.  Researchers  have  devel¬ 
oped  a  plethora  of  different  proposals,  such  as 
TCP-ELFN  and  TCP-BuS,  which  leverage  cross¬ 


layer  feedback  mechanisms  that  provide  notifica¬ 
tion  of  route  or  link  failures  from  intermediate 
nodes  along  the  communication  path  [10].  While 
these  solutions  achieve  better  performance  than 
COTS  TCP  implementations,  they  do  not  pro¬ 
vide  applications  with  fundamental  features  for 
the  tactical  networking  environment. 

Other  transport  protocol  proposals  imple¬ 
ment  a  richer  programming  model  that  goes 
beyond  the  reliable  stream  communication 
semantics  of  TCP.  The  Transport  Protocol  of 
the  Space  Communications  Protocol  Standards 
(SCPS-TP)  [3]  was  originally  developed  for 
space  communications,  but  is  also  proposed  for 
tactical  networks  as  these  share  common  charac¬ 
teristics  such  as  dynamic  topology,  intermittent 
connectivity,  and  bandwidth-constrained  links 
with  high  bit  error  rate.  SCPS-TP  proposes  a 
simple  TCP-like  API  as  well  as  an  extended  API 
with  support  for  message-oriented  communica¬ 
tion,  message  prioritization,  and  full,  partial,  or 
minimal  reliability.  The  Stream  Control  Trans¬ 
port  Protocol  (SCTP)  [2]  also  supports  message- 
based  communications  with  partial  reliability  and 
unordered  delivery,  and  allows  several  streams 
of  communication  in  the  same  connection.  While 
SCPS-TP  and  SCTP  are  better  suited  than  TCP 
for  tactical  networks,  they  still  fall  short  of  pro¬ 
viding  applications  with  critical  features  such  as 
traffic  prioritization,  advanced  transmission 
queue  control,  and  external  control  over  runtime 
properties. 


The  Mockets  Communication 
Middleware 

The  Mockets  middleware  is  an  application-level 
communications  middleware  designed  for  tacti¬ 
cal  networks.  Mockets  addresses  the  specific 
requirements  of  this  environment  as  detailed  in 
the  previous  section  by  providing  applications 
with  a  wider  range  of  features  and  a  richer  pro¬ 
gramming  model,  which  were  purposely 
designed  for  tactical  networks  and  evaluated  in 
the  context  of  several  live  experiments.  This  sec¬ 
tion  briefly  summarizes  the  important  features 
of  Mockets.  Additional  details  may  be  found  in 
[11,  12]. 

The  Mockets  research  project  began  in  2003 
with  ARL’s  participation  in  QL-1.  This  experi¬ 
ment  provided  an  opportunity  to  understand 
the  types  of  applications  used  in  tactical  net¬ 
works  and  their  communication  requirements. 
Moreover,  observing  the  network  and  applica¬ 
tion  behavior  provided  valuable  insight  into 
essential  requirements  and  abstractions  for  the 
middleware.  Participation  in  QL-2  in  2004  and 
C4ISR  OTM  from  2006  to  2008  facilitated  an 
iterative  design,  testing,  and  evaluation  process 
for  the  Mockets  middleware.  Lessons  learned 
from  each  successive  experiment  led  to 
enhancements  to  the  design  and  implementa¬ 
tion  of  Mockets  in  the  context  of  ground-based 
tactical  edge  networks.  Finally,  in  2008,  AFRL’s 
participation  in  a  live  flight  demonstration  of  a 
Joint  Surveillance  Target  Attack  Radar  System 
(J-STARS)  aircraft  communicating  with  a 
portable  ground  station  provided  valuable 
insight  into  the  airborne  networking  environ- 
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ment,  allowing  for  the  extension  of  Mockets  to 
support  this  environment.  During  these  live 
experiments,  we  had  the  opportunity  to  deploy 
Mockets  on  a  wide  variety  of  network  plat¬ 
forms,  ranging  from  802. 11 -based  ad  hoc  nodes 
to  JTRS  prototypes  to  currently  deployed  radios 
such  as  PSC-5. 

Multimode  Communications 

Mockets  supports  and  fosters  a  closed-loop  feed¬ 
back  based  adaptive  programming  model.  Appli¬ 
cations  provide  the  middleware  with  messages 
and  metadata  on  how  to  deliver  them.  In  turn, 
the  middleware  provides  applications  with  infor¬ 
mation  about  current  network  conditions  so  that 
they  can  tailor  their  current  service  rate  and 
message  delivery  semantics. 

More  specifically,  Mockets  provides  applica¬ 
tions  with  connection-oriented  message-based 
communication  facilities.  Mockets  allows  appli¬ 
cations  to  create  several  data  flows  for  each  con¬ 
nection.  Applications  can  assign  specific  message 
delivery  semantics  and  QoS  policies  to  each  flow 
and  change  them  at  runtime.  Specifically,  Mock¬ 
ets  allows  applications  to  choose  between  orthog¬ 
onal  reliable/partially  reliable^/unreliable  and 
sequenced/unsequenced  delivery  semantics. 

Message  Replacement 

Mockets  provides  advanced  queue  control  func¬ 
tions  that  allow  applications  to  prioritize  the 
transmission  of  a  specific  message  within  one 
flow,  to  delete  outdated  messages  in  the  trans¬ 
mission  queue,  or  to  replace  them  with  newer 
messages.  These  functions  were  designed  to 
reduce  network  traffic  and  message  latency,  and 
proved  to  be  very  effective  when  dealing  with 
time-sensitive  information  such  as  position 
updates  in  BFT  applications. 

Rich  Applications  Programming  Interface 

Mockets  enables  the  development  of  adaptive 
applications  by  monitoring  network  status  and 
providing  the  collected  information.  For  conve¬ 
nience,  Mockets  offers  a  double  interface:  appli¬ 
cations  can  either  directly  query  the  middleware 
or  request  to  be  notified  via  callbacks  when  a 
specific  event  occurs,  such  as  the  connection 
quality  falling  below  a  threshold. 

Finally,  Mockets  can  send  connection  status 
information,  including  event  notifications  such  as 
connection  setup,  teardown,  and  connectivity 
loss,  to  an  external  monitoring  application.  This 
feature  enabled  development  of  the  Mirage  visu¬ 
alization  tool  (Fig.  2),  which  proved  invaluable 
to  monitor  the  runtime  behavior  of  applications 
in  live  experiments  and  identify  and  correct 
anomalous  behavior. 

Implementation  Approach 

Implementing  Mockets  as  middleware  provided 
several  advantages  including  phased  integration 
and  portability.  Mockets  uses  UDP  and  hence 
operates  on  any  platform  supporting  a  TCP/IP 
stack,  regardless  of  the  underlying  hardware  and 
operating  system.  We  have  developed  applica¬ 
tions  running  on  gateway  nodes  to  use  both 
Mockets  and  TCP  concurrently  —  Mockets  to 
communicate  with  tactical  edge  nodes  and  TCP 
to  communicate  with  higher-echelon  legacy  sys- 
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Figure  2.  Mirage  visualizer  showing  active  Mocket  connections. 


terns.  Mockets  is  implemented  in  C-F-F,  with 
bindings  for  Java  and  C#.  Mockets  also  provides 
a  TCP-compatible  API  that  allows  COTS  appli¬ 
cations  to  be  gradually  ported  to  the  tactical 
environment,  supporting  and  facilitating  a 
phased  transition  process. 

Experimental  Results 

We  present  results  from  two  experiments  to 
illustrate  the  performance  advantages  that  can 
be  achieved  through  an  integrated  and  tailored 
approach  like  Mockets.  The  first  results  are 
from  AFRL  J-STARS  ANE,  which  used  an 
ARC-231  radio  communicating  with  a  ground- 
based  PSC-5  tactical  radio  link.  The  PSC-5 
adopts  a  demand-assigned  multiple  access 
(DAMA)  MAC  protocol  on  top  of  time-division 
multiple  access  (TDMA)  with  adaptive  slot  size 
and  provides  a  half-duplex  link  with  a  maximum 
data  rate  of  56  kb/s. 

During  the  experiment,  the  aircraft  transmit¬ 
ted  a  series  of  JTIDS  (ground  track)  messages  in 
addition  to  servicing  queries  for  generic  text 
messages  (ROE,  ATO)  from  the  ground  client. 
In  all,  113  JTIDS  messages  and  293  query  results 
were  received  from  the  aircraft  by  the  ground 
client. 

As  the  data  transfer  was  highly  asymmetrical, 
DAMA  assigned  most  of  the  communication 
channel  to  the  ground  station,  effectively  pre¬ 
empting  channel  use  from  the  aircraft.  This 
caused  poor  performance  using  COTS  TCP 
implementations  because  of  timeouts  in  ACK 
transmissions  from  the  aircraft  to  the  ground 
station.  We  achieved  an  8x  performance 
improvement  by  adapting  Mockets  to  work  over 
a  half-duplex  link.  Specifically,  we  disabled  con¬ 
gestion  control  and  forced  the  middleware  to 
periodically  release  the  channel  by  not  transmit- 


^  Partial  reliability  is  a 
trade-off  between  reliabili¬ 
ty  at  any  cost  (like  TCP) 
and  unreliable  delivery 
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prior  to  discarding  a  mes¬ 
sage. 
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Figure  3.  Latency  comparison  between  Mockets,  SCTP,  and  SCPS-TP. 


ting  for  a  few  hundred  milliseconds  after  a  con¬ 
figured  period  of  time. 

We  replicated  the  scenario  in  a  controlled 
laboratory  environment  using  a  hardware  radio 
emulator.  The  results  collected  in  the  laboratory, 
consistent  with  those  achieved  in  the  field,  show 
that  Mockets  performs  better  than  TCP,  provid¬ 
ing  the  same  8x  improvement  in  throughput 
(3292  b/s  for  Mockets  and  432  for  TCP).  Most 
other  transport  protocols  use  acknowledgment- 
based  clocking  and  congestion  control  mecha¬ 
nisms  similar  to  TCP  and  would  therefore  show 
similar  results. 

The  second  experiment  demonstrates  the 
effectiveness  of  Mockets-enabled  advanced 
transmission  queue  control  in  mitigating  the 
impact  of  abrupt  network  changes  on  latency.  To 
this  end,  we  evaluate  the  performance  of  a  sur¬ 
rogate  BFT  application  using  Mockets,  SCPS- 
TP,  and  SCTP. 

The  BFT  application  transmits  1  kbyte 
updates  for  each  node  at  a  rate  of  1  Hz.  With  a 
seven-node  configuration,  clients  receive 
updates  at  an  average  rate  of  one  every  142  ms, 
for  a  total  throughput  of  7  kbytes/s.  To  reduce 
latency,  we  configured  the  Mockets-based  appli¬ 
cation  to  exploit  message  replacement.  More 
specifically,  new  position  messages  replaced  pre¬ 
vious  messages  in  the  transmission  queue.  This 
BFT  application  operated  on  an  emulated  net¬ 
work  that  provided  a  30  kb/s  link.  Periodically 
(every  45  s),  the  quality  of  the  link  dropped  to  a 
5  kb/s  link  for  15  s.  Figure  3  shows  the  mea¬ 
sured  delivery  latency  for  the  first  1300  mes¬ 
sages  transmitted. 

When  the  bandwidth  drops,  messages  accu¬ 
mulate  in  the  transmission  queue.  By  replacing 
old  enqueued  messages  when  a  new  message 
becomes  available,  Mockets  transmits  fewer 
and  more  recent  messages,  thus  achieving  a 
16-24X  decrease  in  latency.  The  latency 


improvement  is  made  possible  by  Mockets  hav¬ 
ing  additional  information  from  the  application 
on  how  to  handle  the  data,  delineating  the  traf¬ 
fic  into  individual  messages,  and  having  suffi¬ 
cient  information  to  determine  when  a  new 
message  makes  previously  enqueued  messages 
obsolete. 


Conclusions 

In  our  experience  with  net-centric  operations, 
the  peculiar  characteristics  of  tactical  networks 
present  challenging  issues  that  need  to  be  specif¬ 
ically  addressed  in  the  realization  of  net-centric 
applications.  Our  work  demonstrates  that  a  com¬ 
munication  middleware  for  tactical  environments 
specifically  designed  to  consider  application 
requirements  and  communication  patterns  can 
significantly  improve  both  performance  and 
robustness.  The  Mockets  communications  mid¬ 
dleware  addresses  many  of  these  challenges,  as 
evidenced  by  our  experiments  in  the  field  and  in 
laboratory  settings. 

We  hope  that  readers  will  benefit  from  our 
experiences  and  understand  the  importance  of 
tailoring  the  design  and  implementation  of  trans¬ 
port  protocols  and  communication  systems  to 
both  the  applications  and  the  target  environ¬ 
ments.  Enhanced  APIs  that  allow  better  integra¬ 
tion  between  applications  and  the  middleware 
are  important.  These  APIs  need  to  support  a 
phased  transition  path  from  COTS  protocols, 
such  as  TCP,  that  are  designed  for  Internet-style 
environments.  We  hope  that  our  experiences 
and  results  also  lead  to  future  standardization 
efforts  for  middleware  and  transport  protocols 
suitable  for  tactical  environments. 
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